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Guidelines for Submission of Newsletter Material 


I would like to use the modern text preparation and communications facil- 
ities of UNIX to as great an extent as feasible in the preparation of the 
Newsletter. I have established an account on our PWB/UNIX system so that 
those who can provide us with machine manageable material can do so. The 
telephone number is (512) 474-5511. The login name is login and the password 
is usenix. (The system is also host utexas on the ARPANET.) 


For those submitting paper copy of material, please produce your copy on 
a daisy wheel printer or similar high quality printing device, Line printer 
produced copy is typically not adequate for reproduction. Copy should be on 8 
1/2" by 11" paper with a 1" margin on left, right, and bottom and 1 1/2" mar- 
gin on top. 


U. 5S. Mail submissions should be addressed to: 
Login Newsletter 
Computation Center 
The University of Texas 


Austin, Tx 78712 


Attn: Wally Wedel 
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Uni-ops Association Formed 


A new users group is being formed which is designed to facilitate commun- 
ications between users of UNIX and UNIX-like Systems. The group plans to 
issue a monthly newsletter called "Pipes and Filters". A National convention 
is scheduled for October 1981 in San Francisco. 


Membership in Uni-ops is open to any interested person at $24 a year. 
Uni-ops mail address is Post Office Box 5182, Walnut Creek, California 94596, 
Telephone is (415) 933-9564, mornings. 


News about UNIX 


BIZCOMP Series 1030 Intelligent Modem 


Samuel J. Leffler 
Sytek, Incorporated 
1153 Bordeaux Drive 

Sunnyvale, California 94086 
(408) 734-9000 


With the release of Version 7 UNIX, Many people started to use the UNIX to 
UNIX copy (uucp) utilities distributed with it. However, for most sites, uucp 
use has been severely limited by the availability of an Auto Call Unit (ACU) 
with which to initiate transactions. This isolation has become even more 
keenly felt now that a UNIX User's Network has come into existence and grown 
to a fairly large size, This note describes our experiences with the BIZCOMP 
Series 1030 Intelligent Modem. The BIZCOMP is an inexpensive ACU which we 
have recently gotten, and are using with uucp to become an active host on the 
uucp—based UNIX network. 


A 1030 is actually a 300 baud, Bell 103, modem with a microprocessor of 
some sort inside (I haven't gotten a chance yet to open it up to see what's 
inside). The modem may be used in auto-answer mode or, by simple ASCII keys- 
trokes, can be configured to originate calls. When acting as an auto-dialer 
the BIZCOMP is supplied ASCII commands to dial a given phone number, then 
Places the call, and if successful goes into a ‘‘transparent mode'', To break 
a connection one sends the BIZCOMP a progranmable escape sequence. The 
BIZCOMP also comes in several factory options: a -068 options silences echo- 
ing of the commands supplied it, -08 options Suppresses the transmission of an 
““auto-id'! character upon completing a connection (used by two cooperating 
BIZCOMPS to synch up). Our BIZCOMP cost less than $500. A comparable DN-11 
like ACU requires two machine ~*ports'' on a system to establish a connection 
and costs upwards of $2000 (I believe for VADIC ACU's). A future model, the 
1022, i8 supposed to cost $595, is more oriented for pure ACU use, but won't 
be available till March at the earliest. 


Given this new toy I couldn't resist integrating it with uucp and another 
program, tip, which is similar to the Version 7 utility cu (used to provide a 
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“virtual terminal interface'' to another UNIX system). The job of talking to 
the BIZCOMP was tedious at first, but eventually handled for tip. The general 
procedure is: 


1, try to synch up the modem by flushing input queues of the associated ter- 
minal, then set its prompt to something well known (I used a **>'* but 
discovered that this echoed as ~*>\0''), 


2. define the sequence of characters which will break a connection and hang 
up the phone (I use “Q*U*I°T for reasons which will be described below) 


3. just to be safe kill the auto-answer on the modem 


4, set the type of dialing to be performed to tone dialing or pulse dialing 
(tip and uuep data bases are consulted to decide which is best for the 
destination host, but see below) 


5, dial the host with a repeat dial command -- this causes the BIZCOMP to 
continuously dial the phone number till it establishes a connection, or 
until any character is sent to the BIZCOMP to abort the dial 


6. if a ~"NO CONNECTION'' message comes back you got a busy signal, other- 
wise you should get a ~~CONNECTION'' message 


7. carry on your dialogue with the destination host 
8. break the link with the escape sequence defined above 


This procedure should be tempered with a couple of notes. When I initiate 
dialing I also set up a timeout of 60 seconds. The repeat dial command goes 
on forever, so this must be done. I had previously tried a one shot dial, but 
found that this was very unreliable, so resorted to the brute force way. 


The question of using tone dialing or pulse dialing is pretty much a mys- 
tery to me. It is based on what kind of local exchange you have (certain 
exchanges don't support tone dialing). Tone dialing is the preferred method 
used by the phone company, but often was found not to work (even to local 
numbers, though we have a local exchange which should support it). Therefore, 
I tried dialing numbers by hand and adjusted system tables to reflect my find- 
ings. The majority of the phone numbers I use are dialed with pulse dialing. 


The use of the ***Q*U*I°T'' escape sequence turned out to be a stroke of 
luck when used with the tip program, Since “Q is normally the X-ON character 
used by UNIX when a terminal is in TANDEM mode, it is not possible for a user 
to intentionally break a phone connection when using tip. This is important 
to us because tip is outfitted to maintain accounting of ACU usage (phone 
number, length of time on the line, etc.). 


The addition of the BIZCOMP to uucp was also quite simple. The major 
problem was that uucp doesn't think you're going to use anything but a DN-11 
like ACU. Consequently a bit of hacking was performed on one routine in order 
to add the required code. 
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While we haven't been using the BIZCOMP for very long, it seems to be 
working fine. For the impoverished UNIX site it appears to be a nice inexpen— 


sive addition, Any and all software I've developed for the BIZCOMP is avail- 
able from me for free. 


MX_- An indirect driver for multiplexing virtual “‘tty'' lines 


Piers Lauder 
Basser Department of Computer Science 
Sydney University 


The "mx" driver on Unix implements virtua] "tty" lines, multiplexing them 
onto physical "tty" lines via a simple protocol. The protocol introduces a 
traffic overhead of approximately 20%, and includes flow control. "Mx" is 
Most often employed in inter-machine networks where the number of physical 
connections is limited, or is used by concentrators for terminals and line 
printers. 


The mx driver has spread around the Sydney Unix Network as an easy way of 
getting many virtual connections out of a few expensive long distance connec- 
tions. The mx protocol is essentially a communications protocol tailored for 
ease of grafting onto the Unix tty driver. It is also used to interface dif~ 
ferent networks to the Unix net, and to connect slow terminals via concentra- 
tors onto higher speed lines, From the point of view of a user, an mx port 
behaves exactly as a standard Unix tty interface. 


Protocol 


The mx protocol multiplexes "mx ports" onto "real lines" and essentially 
just separates data for each port on a line. The protocol blocks data with a 
4 byte header: 





start-of-header; 
port-id; 
data—byte-count; 
inver se-byte-count; 
data ... 


This four byte header is eaSily recognized and checked for consistency with 
the repeated byte count. The data length is kept small, in the region of 40 
bytes. Flow control is implemented by empty blocks with the first byte count 
zero, and the second byte count representing the flow rate granted before 
receipt of the next flow control block. It is important to note that flow 
rates granted are not cumulative, and thus hung lines can be restarted via a 
simple timeout mechanism, 
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Interface 


The tty interfaces provided by the mx driver appear to the user to be 
identical to ordinary tty lines as implemented by other Unix tty drivers, In 
fact the user interface is provided by the common routines implemented in the 
file tty.c, The device interface uses device driver routines via the cdevsw 
procedure ‘array and assumes that they manipulate common Unix tty structures, 
A few changes have been made to the tty.c routines to identify those lines 
that have indirect drivers such as mx hanging off them. This is used to vec= 
tor input through a pointer in the tty structure to the input handling routine 
in the indirect driver. A timeout scan in the mx driver is used to keep up 


output flow by examining the virtual and real output queues, 


Output 


When a write is made on an mx line the data is accumulated on the mx out- 
put queue until either the maximum block size is reached, or the user write 
call terminates. At this point output flow rates are checked and used to 
limit the next stage. Then the data is blocked up with its protocol header 
and transferred to the real driver's output queue, for later transmission. 


Input 


Input bytes via the real device are vectored through ttyinput which in 
turn calls mxinput. Mxinput examines the bytes for protocol headers using a 
simple state machine. When a flow control block is identified the "flow 
enabled" count is reset. When data blocks are identified, the bytes are 
passed via ttyinput to the appropriate "mx tty" input queue for retrieval by a 
user read call. A flow control grant block is generated whenever the user 
input queue is low enough. This is checked as soon as the byte count is 
encountered, thus providing a certain amount of "read-ahead", 


For maximum efficiency, user writes should be of the order of the maximum 
block size. However many Unix programs generate 1 byte writes to tty inter- 
faces, thus causing protocol overheads of 400%, and most line degradation is 
caused this way. Flow control is granted in small lots equivalent to the max- 
imum size of a data block, doubling the effective overhead. The recursive 
calls of the tty routines at interrupt time cause a much greater system over- 
head in indirect drivers implemented this way. 


Conclusions 


As the real traffie rates on high speed lines connected to terminals are 
much lower than the maximum, the protocol overhead of the mx driver is accept- 
able. Furthermore, output and input data rates for high speed terminals typi- 
cally differ by a factor of 10 to 1, so two ports operating in opposite direc- 
tions on the same line have a low impact on each others apparent speed. 
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Implementation 


All the mx driver needs to know about each real tty line is the device id 
(major, minor), the number of ports to be multiplexed onto the line, and the 
baud rate, 


These details are initialized in the configuration structure "mxdev" - 
just alter it to reflect the local conditions. A tty structure ig declared by 
"mxtty" for each port, so, on some small systems with kernel memory limita- 
tions, the number of ports should be kept small. 


Mxtty is allocated as a contiguous array, and therefore minor device 
numbers for the special files must be contiguous. This means that if you want 
to change the number of ports on the first line, the special files will have 
to be remade for all the other lines. 


The structure "mxmap" maps each real tty onto the "ported" tty struc- 
tures, and contains current information about block transfers. 
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SUN - The Sydney Unix Net 


Piers Lauder 
Basser Department of Computer Science 
Sydney University 


ABSTRACT 


The Sydney Unix Net is a simple implementation of a user initiated file 
transfer facility. SUN is a "host supported" network, and considerations of 
low overhead have lead to an efficient design, The network is self configur- 
ing with an optimal routing algorithm. 


Introduction 


SUN consists of linked hosts (nodes) with unique names, where links 
between nodes may be unreliable and quite slow. Using this network, a simple 
system has been developed to provide reliable host-host file transfer. The 
system is implemented in two levels. Level one provides an error free path 
between nodes, and level two implements a host-host protocol, and maintains a 
network topology file for routing calculations, Files are transmitted through 
the network until they reach their destination where they are spooled for 
later collection by the remote user, who is informed by mail of the arrival of 
files from the network. 


User Interface 


The user interface is as simple as possible, A network address is 
defined as a usSername:.I host pair, i.e. the name of the user on the remote 
host is separated from the remote host name by a colon. This form of address 
is understood by the mail programs, some print commands, and the netsend com— 
mand, 


Two special file transfer types are recognized in addition to user-to- 
user file transfers, namely mail and print. Mail is automatically delivered 
on the remote host by invoking mail, and print files are handled by invoking 
the print spooler, but user files are spooled in a holding directory for later 
collection by the designated user. The arrival of files is notified by mail 
to the user. To complete the file transfer (and assume ownership of the 
file), a user must invoke the netget program to retrieve the file from the 


holding directory. Uncollected files can be easily discarded from time to 
time. 


Design 


The network programs operate on two levels with clearly defined inter- 
faces, The top level (implemented by the program net) accepts files for 
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transmission, calculates the next node in the path, and spools the file 
together with a host/host protocol header in a directory naming the next host. 
The lower level (implemented by the program netd) accepts files for transmis- 
sion to an immediately connected host, negotiates with the lower level on the 
remote host for file transfer to start, and then uses a node/node protocol to 
transfer the file reliably, On arrival at the next node, the file is passed 
to the upper level for any further routing. 


The file transfer mechanism is half-duplex at the lower level, and 
Store-and-forward at the higher level. 


Node/Node Interface 


The link between hosts provided by the operating system must be a full 
duplex, byte oriented special file. The name of this special file is that of 
the node to which it is connected at the remote end. This file is opened for 
reading and writing by the network daemon responsible for communicating with 
the next node, 


Actual links between hosts may be physical RS232 type lines, either 
directly connected, or via telecommunications modems, and be handled by the 
Standard Unix tty interface. Many hosts multiplex the physical link using the 
mx tty interface (mentioned elsewhere) to which the network requires only one 
port. 


Node/Node Protocol 


The network daemons communicate with each other over the node-node inter 
face, They use a half—duplex, multi-buffered, positive acknowledgment data 
transfer protocol. Before file transfer starts, the daemons negotiate the 
direction of the next transfer. File transfer proceeds with short data blocks 
enclosed in a protocol envelope consisting of a header and a trailer. The 
header contains a sequence number used to provide the multi-buffered message 
flow, and the trailer implements a simple low-cost error detection capability. 
Messages must be acknowledged (positively or negatively) with a two byte reply 
consisting of ACK or NAK and the relevant sequence number. Errors cause the 
re-transmission of all un-acknowledged blocks, Catastrophic error conditions 
Cause a negotiation for file transfer restart. 


Daemon/Spooler Interface 


The interface between spooler and daemon is defined by queued files. 
Each daemon maintains a command directory which it scans for command files. 
Each command file specifies the path names of files for transmission. The 
Spooler .chooses the next host for transmission by the fact that the name of 
the host is also the name of the command directory for the appropriate daemon. 
On the other hand, files received by the daemon are passed directly to the 
Spooler program. 
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Host/Host Protocol 


The network routing program net (the "spooler" referred to above) 
prepends a host-host protocol header to each file before spooling it in a dae- 
mon directory for transmission to the next host. This header contains the 
Source and destination network addresses together with routing information and 
file parameters. Each file arriving from the net is examined for this header 
and re-routed if the destination is not yet reached. Each host through which 
the file passes adds a host/time record to the routing information in the 
header. Amongst other things, this information can be used for network per- 
formance analysis. 


Topology File 


The routing information in each file header is used to maintain the 
topology file. Each host mentioned in the route is connected to the preceding 
and succeeding hosts, and these links are maintained in the topology file. It 
is possible for a topology file to become aware of new hosts in this way, how- 
ever there are special files whose purpose is to maintain network topology 
files generally. Thus there are "host-up" messages to inform the network of a 
new hosts, and "host—-down" messages to inform the network of broken links. 
These messages are broadcast around the network by the net programs who also 
stop any loops. New hosts coming up receive a special file from any immedi- 
ately connected hosts containing a copy of their topology files, thus immedi- 
ately informing a new host of the latest network state. 


In order to send a file to a remote host, its name must exist in the 
topology file so that the routing program can find it, unless it is directly 
connected. 


Conclusions 


The initial effort producing the software for a usable network took about 
2 man-weeks, Since then many requested enhancements have been implemented 
involving a further 4 man-weeks of work. As it now exists, SUN has proved 
very helpful in bringing together many people involved in cooperative work in 
Support of our various teaching systems. 
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Share Scheduling Works! 


Piers Lauder 
Basser Department of Computer Science 
Sydney University 


ABSTRACT 


The Share Scheduling Algorithm on Unix provides a per-user scheduler on 
top of the standard per-process scheduler. It acts to provide equitable allo- 
cation of the machine between classes of users, and between users of the same 
class, according to their allocation of "shares" of the machine. 


At Sydney University, we have implemented a version of the Cambridge 
Share Scheduling Algorithm as proposed by J. Larmouth of Salford University, 
and modified by Andrew Hume of AGSM. This scheduler has been very successful 
in allocating the limited resources of our student teaching machine (overcom- 
ing the otherwise unrestricted generosity of Unix) and has also been surpris- 
ingly successful as an advertisement for the sophistication of our teaching 
service amongst people who might otherwise consider Unix to be a toy operating 
system unsuited for the real world. 


Implementation 


The Share algorithm allocates a share of the machine to each user based 
on his history of past usage, his current working rate, and the ratio of his 
allocated shares to those of other users concurrently using the machine. 


The algorithm as implemented was extensively modified by Hume (as 
described by Hume in his paper "A Share Scheduler for Unix"). This was mainly 
due to Larmouth's algorithm being batch oriented, whereas an interactive 
environment requires quicker responses. 


The low level scheduler in Unix allocates use of the cpu amongst compet— 
ing processes based on their priority which decays very quickly. Thus every 
Process competes on an equal basis. It is possible for a user to increase his 
Share of the cpu by running many "asynchronous" processes simultaneously. In 
order to allocate the cpu between users, regardless of the number of 
processes, the low level scheduler was changed to use a per-user priority 
which is added to each process's short term priority. This per-user priority 


is manipulated by the Share scheduler to affect a user's long term share of 
the machine. 


To calculate the cost of the user's use of the machine, separate charges 
are made for cpu time, memory occupancy, terminal 1/0, backing store I/O, and 
System services. This cost is added to the accumulating uSage, and the accu 
mulating rate. The rate figure decays quite fast, approximately 10% second, 
whereas the usage decays quite slowly, approximately 10% day. There are thus 
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two separate figures contributing to the calculations for the real share of 
the machine to be allocated in the next time period, one based on recent work- 
ing rate, and the other on long term usage. It is therefore possible for high 
usage users to do a little every now and then, The real share figure is then 
used to affect the user's overall priority. 


The Real Effect 


The Share Scheduler has no effect whatever on an under utilized machine, 
and in practice this means less than 45 users on our VAX 11/780. However, 
ever this, the effects are very satisfactory. To be most useful, there must 
be, at any one time, two or more classes of user with different priority of 
access to the resources, For instance, during class hours, students are 
deemed to have greater rights to a reasonable response than, Say, academic 
staff. This is achieved by an (heuristic) allocation of shares to each class 
of user based on expected average use of the machine, and bearing in mind the 
decay rate of the usage. For example, at Basser we allocate 10 shares to 
first year students (who are expected to use 3 terminal hours per week), 50 
shares to academic staff, and 200 shares to staff programmers. This effec- 
tively bars academic staff from using the machine during periods of heavy 
usage as their figure is always fairly high, whereas first year students 
(whose usage decays substantially between their terminal sessions) can obtain 
reasonable response even during times of peak loading. On the other hand, the 
200 shares allocated to programmers allows them to carry out normal system 
support programming with reasonable response at all times. All this is in 
addition to the fair distribution of resources within each class of user, as 
users who use the machine heavily are not allowed to reduce the response of 
similarly classed people who are working lightly. 


With 45 users experiencing good response, it would appear that each user 
needs around 2.2% of a VAX 11/780, and it would be reasonable to nominate a 
share figure, say 0.5%, below which the system should actively discourage 
users from logging in, although we haven't done this. The consequence of not 
doing this, is that if a user's share drops below say 0.1% during a session 
when many more people have logged in, he may get "marooned" with insufficient 
resources to allow log off (there being no cpu allocation enough to execute 
the "exit" system call from the shell!). 


A user may discover his share during a terminal session, and watch. it 
change as costs are incurred, and he is of course informed of it at login, 
However the changes can be quite dramatic if for instance a user is the first 
of 75 to log in after a system reboot, It might be advantageous to inform a 
user whose share has dropped below a magic figure during a session, so that he 


has a reasonable chance to log off and let someone else use the terminal to 
greater advantage, 


Tools 
There are various system monitoring programs to display the performance 


of the scheduling algorithm, and nearly all parameters can be changed dynami- 
cally. In particular all charges can be varied to reflect administrative 
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policies about system resource costs. At Basser we charge at a fixed rate 
between Jam and Spm of a working day, 50% of that until 10pm, and 10% over- 
night. Also users using the "nice" command get charged less for cpu time as 
appropriate. 


Implementation 


The actual scheduler is one page of C code and uses floating point exten- 
sively, although Hume has proposed a model using integer arithmetic. On the 
Vax, floating point is easier as the code is much cleaner, and the floating 
Point instructions are reliable. The C compiler produces extremely ineffi- 
cient floating point code, nevertheless, running once every 4 seconds, the 
Scheduler consumes less than 0.5% of the cpu time managing 80 users on the 
VAX. Recoding the algorithm in assembler would reduce this to around 0.2%, 


Charges are levied throughout the system at the various "cost" points. 
This is done by adding a variable charge for the resource type (obtained from 
a charges array) into a per-user "cost" variable. 


The scheduler is invoked by the clock interrupt routine requesting a 
software interrupt at a low priority, once every 4 seconds, 


The algorithm first scans all the per-user structures building up an idea 
of total rates and shares, and simultaneously decaying the usage and rate fig- 
ures after adding in the cost, The rate and usage totals are then biased by 
(tunable) factors reflecting their relative weights in the priority calcula- 
tion, 


A second scan of the per-user structures then calculates the per-user 
priority to be used by the low-level scheduler. A user's share of the machine 
is thus reflected in his priority relative to the priorities of all other 
users, 


Example Monitor Output 


The following is a typical output produced by one of the monitor programs 
used to tune the algorithm. 
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Wed Oct 22 16:49:37 1980 


Lnodes: 78 Users: 76 Averages: 

Usage factor Rate factor Total rate rate usage shares 

4,224907e-05 1.34393 1e-03 2172346 21609 8.373e+07 37.1053 

Constants:- 

syscall: bio tio tic click maxnice ufactor rfactor usagek 
1360 1000 283 8333 1 18 1 2 0.9999834 


aH 

HE 

HERE 

HEH 

ERREH 

HEH 

HEH 

HEHE 

Poe r # 
EE * * 
HE * 
EEE EE EE EE EE HEH 


0246802468 background = 1 


There are 76 users logged on, not including the idle process and the system 
user (root). The "Usage" and “Rate” factors are intermediate values used by 
the scheduling algorithm, the "Total rate” value includes that of the system 
and the idle process, whereas the averages are for "real" users only. A real 
user is one who has been allocated shares, The constants refer to the charges 
being made for each of the resources, "usagek"t is the rate of decay applied to 
usage figures, effectively 20% per day. 


The histogram shows the number of users vs, their priority. 
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Modifications for Unix on Small CPU's 


Kenneth A. Reek 
School of Computer Science and Technology 
Rochester Institute of Technology 
One Lomb Memorial Dr. 
Rochester N. Y. 14623 


Like most other university environments, we at RIT have needs for comput— 
ing equipment far greater than can be satisfied by our computing budget, so we 
make do with what we can get. We are, therefore, another of the few installa- 
tions running 7th Edition Unix on a "small" PDP-11, that is, one lacking 
Separate instruction and data spaces. We wanted to support at least a half~ 
dozen users running rather large programs, so we decided to solve the size 
problem and the resulting crunch on buffers by modifying the kernel. 


The primary change was to remove the system's buffers from the kernel 
address space, We had heard that this had been done before, but somehow never 
got the name of anyone who had done it (or never got around to contacting 
them). Our change, then, is an independent effort, so we are interested in 
exchanging ideas with anyone else who has done this. 


It turns out that there are only a few places in the kernel outside of 
I/O drivers where the buffers themselves (as opposed to the buffer headers) 
are actually accessed. It is these places that are affected. .No changes are 
needed in the I/0 drivers, since the device controllers do not know about 
"address spaces", 


Instead of declaring space for the buffers themselves at compile-time (in 
Main.c), we allocate space for them during system initialization by calling 
"malloc" from "binit", We have only one buffer in the kernel address space 
which is used as a scratch pad. Our implementation is limited to at most 32 
buffers to guarantee that they fall into physical Memory whose high-order two 
bits are both zero, which simplifies accessing them. We have assembly 
language routines to copy data into and out of the buffers, which is accon- 
Plished by "borrowing" the kernel's mapping register number 1, and changing it 
to point to the desired buffer. That Particular register is safe to use 
because it does not cover the assembly routines themselves (m40.s is less than 
8k bytes) and it does not cover any data (the kernel code is larger than 16k 
bytes). Copying is done at high priority to prevent any interrupt service 
routines from trying to access the code normally serviced by register 1. 
After the data is copied into or out of the buffer, the previous values are 
restored to the map. We consider this to be a very conservative (i.e. 
Kludgy), but safe approach. On an 11/34, it takes about 1.7 milliseconds to 
copy a buffer, so the only devices that would be affected are those that 
require interrupt service within that interval, such as a character multi- 
plexor without a silo receiving at 9600 baud. We have nothing like this, so 
it isn't a problem for us. 


The assembly language routines are called whenever the kernel accesses a 
buffer, Many of the accesses use "beopy", and in these instances the only 
change needed is to substitute one routine for the other. For accesses where 
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the code itself pokes around in the buffer (as in updating inodes), we call 
our routine to copy the desired buffer into the scratch pad, modify it, and 
then copy it back into the real buffer. Being overly cautious, we protect the 
scratch pad buffer with code that guarantees its exclusive use by reporting 
any collisions via a "panic". The only time such a collision occurred was 
when the system was already crashing for an unrelated reason. 


This change frees up the kernel space that is normally taken by buffers 
so it can be used for other data structures. We now have 25 buffers, and 
enough space left for lots of inodes, file structures, and the like. 


A couple of other changes we have made might be of interest to some 
users. Rather than using system buffers to hold the super-block of mounted 
file systems, we allocate space at compile-time for the desired number of 
mounted file systems, If all the file systems are usually mounted all of the 
time, this buys a little memory, since the super~block structure is smaller 
than a buffer and no header is needed, If, however, your system normally has 
Several unused mount entries, then there will be a net loss in space, 


We also removed all of the tunable constants from the source files and 
replaced them with references to a table where the desired parameters are 
stored, By changing "mkconf", we create this table in ¢c.c, along with all the 
data structures that depend on tunable parameters. In this way, changing 
these parameters does not require recompilation of the system (though the syn- 
bol table in the C compiler had to be enlarged to handle the additional sym— 
bols). Also, by modifying programs such as "ps" and “pstat" to examine the 
table in the kernel, they need not be recompiled each time the system is 
tuned. This saves us a lot of time, since we like to fiddle with these things 
frequently. 


We use our PDP-11/34 to support student projects in courses that deal 
with programming I/O devices and handling interrupts. The single-user systems 
that we used in the past (of which the 11/34 was one) simply could not handle 
the increased enrollment in the courses, prompting us to investigate the use 
of some kind of timesharing. The problem with using a timesharing system for 
this application is obvious, however. Since many users are working on their 
programs, users cannot run their programs because doing so would crash the 
timesharing system. 


We currently have 3 LSI-11 microcomputers connected to the system, any of 
which can be accessed from each of the 7 user terminals. The program that 
communicates with the LSI's sets things up so that the user's terminal acts 
like the console terminal for the LSI, allowing the user to make full use of 
the console emulator and its debugging capabilities. The program also pro- 
vides users with the capability of sending their programs to the LSI-11 for 
execution, which solves our timesharing/single-user dilemma, Numerous debug- 
ging and development utilities have evolved to further simplify the student's 
task. With this arrangement, we can support (and give better programming 
facilities to) a much larger student population than would have been possible 
by simply buying more single-user systems. 


We will send the kernel modifications and any of the other stuff we have 
to all interested (but authorized) parties who can take 800 or 1600 bpi tapes 
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in "tar" format. Send a copy of the identifying part of your license, along 
with $10 for postage and handling. Delivery time is an exponential function 
of the number of ungraded tests on my desk at the moment. 


USENIX ASSOCIATION 
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